1. Field of the Invention
This invention relates to computer processes and, more particularly, to the instrumentation of computer application code.
2. Description of the Related Art
In order to gain a fuller understanding of the operation of software processes, it is common to employ any of a variety of monitoring, profiling, and/or analysis programs in conjunction with the software processes to be understood. Such monitoring, profiling, and analysis programs which, for simplicity, may collectively be referred to as “profilers”, are available from many vendors or may be custom-made for specific applications. As part of a profiling or monitoring process, application code may be “instrumented” by adding instructions (i.e., code) sometimes referred to as “probes” to an application's original code. These probes may then generate additional data concerning the operation of the application during runtime.
Traditionally, there have been two general approaches to the instrumentation of application code. One approach is static instrumentation, and the other approach is dynamic instrumentation. However, both of these approaches have disadvantages. Static instrumentation generally involves replacing an application's original executables with instrumented executables. However, such an approach can be difficult to manage. One difficult with managing statically instrumented applications is the user needs to know which executables make up their application, and which executable are instrumented and non-instrumented. Another problem with static instrumentation is that digitally-signed code generally cannot be instrumented. If a digitally signed assembly, library, or other code is instrumented, the process which loads the instrumented code may reject it due to a failed signature verification.
In dynamic instrumentation, application code (e.g., intermediate code) may be instrumented at the time the code is actually loaded for execution. For example, in the Microsoft®.NET framework, bytecodes may be instrumented when a method or assembly is loaded for just in time (JIT) compilation. Alternatively, code may be instrumented when a class is loaded in a Sun® Microsystems®' Java® environment. While the dynamic approach may avoid the need for replacing deployed executables on disk, it may also entail significant performance implications due to the overhead involved. Further, it may also be very difficult to support and maintain code while using a dynamic instrumentation approach, because no instrumented files are generated that can be sent to support.
In view of the above, an effective and efficient method and mechanism for instrumenting application code is desired.